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Background 

This invention relates generally to processor-based 
systems and particularly to basic input/output systems. 

A basic input/output system (BIOS) is a set of 
software routines that test hardware at start up, start the 
operating system and support the transfer of data among 
hardware devices. Conventionally, BIOS is stored in a read 
only memory (ROM) so that it can be executed when a 
processor-based system is turned on, 

BIOS is conventionally monolithic, in that the files 
making up the BIOS are not separately accessible. The BIOS 
is generally loaded as a whole and executed as a whole. 
This simplifies the operation of the BIOS and may, in some 
cases, when relatively simple processor-based systems are 
involved, speed the execution of the BIOS and improve the 
speed at which a system boots up. 

However, with the advent of increasingly more complex 
functions implemented by increasingly lower cost systems, 
the demands on BIOS have increased. The proliferation of a 
variety of different types of BIOS and a variety of 
processor-based systems from very simple systems to 
extremely complex multiprocessor systems, have increased 
the demands on the BIOS. 



Thus, there is a need for a BIOS which is capable of 
implementing more elaborate capabilities. 

Summary 

In accordance with one aspect, a method includes 
executing a first basic input/output system module. The 
method also includes dynamically linking to a second basic 
input /output system module. 

Other aspects are set forth in the accompanying 
detailed description and claims. 

Rrief Description of th e Drawings 
Figure 1 is a block depiction of a processor-based 

system in accordance with one embodiment of the present 

inventions- 
Figure 2 is a BIOS map for a distributed BIOS system 

in accordance with one embodiment of the present invention 
Figure 3 is a schematic depiction of a preboot 

authentication system in accordance with one embodiment of 

the present inventions- 
Figure 4 is a flow chart for implementing one 

embodiment of the present inventions- 
Figure 5 is a flow chart for implementing another 

embodiment of the present inventions- 
Figure 6 is a schematic depiction of a module in 

accordance with one embodiment of the present invention; 



Figure 7 is a schematic depiction of a descriptors 
table for accessing modules in accordance with one 
embodiment of the invention; and 

Figure 8 is a flow chart for software for implementing 
5 dynamic linking of BIOS modules in accordance with one 
embodiment of the present invention. 

Detailed Description 
Referring to Figure 1, a processor-based system 10 may 
include a processor 12 coupled to an interface 14 . The 

10 interface 14 may a bridge or a part of a chipset, as 

examples. The interface 14 may be coupled to a graphics 
controller 18, for example, by an accelerated graphics port 
(AGP) bus 16. (See Accelerated Graphics Port Interface 
Specification, Rev. 1.0, published July 31, 1996 by Intel 

15 Corporation, Santa Clara, California.) The controller 18 
may control a display 20. The interface 14 may also be 
coupled to the system memory 22. 

The interface 14 may also be coupled to a bus 24. In 
one embodiment of the present invention, the bus 24 is a 

20 Peripheral Component Interconnect (PCI) bus which is 

compliant with the PCI Local Bus Specification, Rev. 2.1, 
June 1, 1995 available from the PCI Special Interest Group, 
Portland, Oregon 97214. 

The bus 24 may be coupled to an interface 26 which may 

25 also be part of a chipset and which may be implemented by a 
bridge as examples. A legacy bus 42 may be coupled to the 
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interface 26. Also coupled to the interface 26 is a hard 
disk drive 28 which may store basic input /output system 
(BIOS) module 30. A module is a file that need not meet 
any of the requirements normally associated with a Disk 
5 Operating System (DOS) file. 

Also coupled to the legacy bus 42 is a network 
interface (NIC) card 32 that allows the system 10 to 
connect to a server 36 over a network 34. For example, in 
one embodiment of the present invention, the connection to 

10 the network and the assignment of Internet Protocol (IP) 
addresses may be handled using Dynamic Host Configuration 
Protocol (see Request for Comments (RFCs) 1534, 2131 and 
2132 available at www.ietf.org) (DHCP). The server 36 may 
include a storage device 3 8 which also stores BIOS module 

15 40 . 

Also coupled to the legacy bus 42 is a BIOS read only 
memory (ROM) 50 that may store additional BIOS module 52. 
In some embodiments of the present invention, additional 
BIOS file storage devices may be coupled to the bus 42 

20 through the interface 44. For example, a smart card reader 
46 may be coupled to the bus 42. The smart card reader may 
read a smart card which stores a BIOS module, as indicated 
at 48. A more detailed description of the operation of 
smart cards and smart card readers, also known as 

25 integrated circuit cards (ICCs) and interface devices 

(IFDs) is set forth in the Interoperability Specification 
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for ICCs and Personal Computer Systems Developed by the 
PC/SC Work Group ; Rev. 1.0, published in December 1997. 

The BIOS, which normally would be stored before 
execution entirely on the BIOS ROM 50, may be distributed 
5 among a plurality of modules stored in a plurality of 

storage devices. Referring for example to Figure 2, the 
unexecuted BIOS may be made up of BIOS module 52 stored in 
the ROM 50, BIOS module 40 stored in the storage 3 8 
associated with the server 3 6 and BIOS module contained on 

10 a smart card 48 read by a card reader 46. Not only may the 
BIOS be stored in devices accessible over the legacy bus 
42, BIOS modules may also be stored on devices accessible 
through the bus 24 as well. 

While an illustrated embodiment discloses a system in 

15 which a distributed BIOS is utilized (BIOS modules are 

distributed among a variety of different memory types and 
locations) , in some embodiments of the present invention, 
all of the BIOS modules may be stored on the same memory. 
For example, any one of the BIOS storing memories 

20 illustrated in Figure 1 may store all of the BIOS modules. 
For example, in one embodiment of the present invention, 
the BIOS ROM 50 may store all the BIOS modules prior to 
execution. 

The control of the various modules may be undertaken 
25 by an interpreter 52a which, in one embodiment of the 

present invention, may be stored on the BIOS ROM 50. The 
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interpreter 52a contains all the directions to the various 
BIOS modules. It reads the various instructions and 
provides instructions about what to do under various 
circumstances. Thus, the interpreter 52a may be 
5 responsible for conditionally integrating the BIOS 
functions into an overall BIOS operation. 

One example of an application of such a distributed 
BIOS system involves preboot authentication services (PAS) . 
It should be understood however, that the application of 

10 distributed BIOS to PAS is merely an example of one 

application which may be implemented using a distributed 
BIOS system and is not intended to be limiting in any way, 

PAS provides different levels of authentication 
depending on the status of the processor-based system. For 

15 example, if the processor-based system 10 is connected to 
the network 34, the possibility of compromising system 
resources is much higher than if the system 10 were 
operated on a stand-alone basis without connection to 
network 34 resources. Therefore, in order to provide 

20 protection for those network resources, the authentication 
protocols for a new user may be implemented variably 
depending on the system state- -in this case whether or not 
the system 10 is connected to a network 34. 

With PAS, some parts of BIOS are optional, not only in 

25 terms that they need not be executed but also because they 
may not exist at all or they may exist conditionally 
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depending on a system state. In one example, the system 
state may be whether or not the system is connected to a 
network. Authentication requirements may be lowered when 
there is no desire to link to the network. 

5 In PAS, when the system 10 is linked to the network 

34, for example through a local adapter or NIC 32, this 
connection may be recognized, and the BIOS may control the 
nature of the authentication. This detection of a network 
connection may be provided through the NIC 32 or, for 

10 example in the case of mobile systems, when the mobile 
system is docked to a docking bay. 

Once network resources may be accessed, the 
authentication requirements may be increased. For example, 
there may be a token file which is also part of BIOS which 

15 may be placed on a network storage 38 such as a network 

drive rather than on the local system storage such as the 
BIOS ROM 50. The BIOS module 40 may be requested by the 
local system 10, loaded and executed for use in 
authentication. Similarly, the system 10 may require the 

20 use of smart card authentication in one embodiment of the 
invention. Again, the PAS system may provide different 
levels of authentication that may specify, not only the 
entry of conventional tokens such as passwords, but also 
the use of a smart card, depending on whether or not the 

25 system 10 is connected to the network 34. 



7 



In one embodiment of the present invention, the BIOS 
module 40 may constitute a network bootstrap program (NBP) . 
NBPs are remote boot images which may be downloaded by a 
client by way of trivial file transfer protocol (TFTP) , 

5 TFTP is an industry standard Internet protocol to enable 
the transmission of files across the Internet. {See RFC 
1350, available at www.ietf.com,) Other file transfer 
protocols may be utilized as well. The operation of a 
system which uses TFTP and NBPs is described in the Preboot 

10 Execution Environment (PXE) Specification, Version 2.1, 

dated September 20, 1999 by Intel Corporation, Santa Clara, 
California (available at www.intel.com) . 

PXE allows for remote new system startup. PXE 
provides a uniform protocol for the client to request the 

15 allocation of a network address and subsequently address 

the download of an NBP from a network boot server. It also 
provides a set of application program interfaces (APIs) 
available on the client's preboot firmware environment that 
constitute a set of services that can be employed by the 

20 NBP or the BIOS. Finally, PXE provides a standard method 
of initiating the preboot firmware to execute the PXE 
protocol on the client. A newly installed network client 
may enter a heterogeneous network, acquire a network 
address from a DHCP server and then download an NBP to set 

25 itself up. Thus, with PXE, a client such as the system 10 
may be connected to a network in an automatic fashion, in 
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the boot sequence, enabling the acquisition of a BIOS 
module from a remote network 34 during the boot process. 

Turning now to Figure 3, the BIOS may begin with the 
initialization of the processor 12, the memory, any 
5 chipsets and the like as indicated in block 54. This is 

the beginning of the boot process. Next, a connection to a 
network 34 may be detected as indicated in block 56. The 
detection of the network may be done through the PXE 
protocol. Since PXE is used to connect to the network 

10 during post and the pre-operating system space, an 

integrated NIC may be polled to determine whether a network 
connection has been automatically set up through the PXE 
protocol. An PXE API may be provided that polls the PXE 
related files to determine the network status. 

15 Next, as shown in block 58, the user authentication 

data may be captured and stored. Of course, the nature of 
the user authentication data may differ depending on 
whether the system is connected to a network. Thus, 
authentication data may come over the network 34 or from 

20 the storage 50 depending on the state of the system 10. 

After the user has been authenticated, a key may be 
obtained from protected storage. The key may be sent over 
a hard disk drive 28, in accordance with one embodiment of 
the present invention. 

25 The OS is loaded, partitions are checked, and 

integrity is determined as indicated in block 62. In the 
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post-operating system or post-OS space, the user may again 
be authenticated using operating system protocols as 
indicated in block 64. If encryption is built into the 
operating system, setup keys for encryption and decryption 
5 may be implemented in some embodiments as indicated in 
block 66. 

Referring to Figure 4, in accordance with one 
embodiment of the present invention, a distributed BIOS 
file system 52 may be executed by determining what system 

10 state exists as indicated in diamond 72. Again, this 
information may be obtained using the PXE protocol. 

Depending on the system state (which in one embodiment 
of the present invention may be whether or not the system 
is connected to a network) , a first BIOS module may be 

15 loaded as indicated in block 74 and executed as indicated 
in block 76, If a different system state exists, a second 
module may be loaded as indicated in block 78. Thereafter, 
this module may then be executed as indicated in block 80. 

Thus, depending on the system state, either a first or 

20 a second module may be located and loaded. Those modules 
may or may not be distributed with respect to one another 
in that one of the modules, before execution, may be 
located in a storage different from the other of the 
modules. The modules may be loaded and executed under the 

25 direction of the interpreter 52a in one embodiment of the 
present invention . 
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Referring next to Figure 5, the application of these 
principles in a PAS embodiment may begin by determining 
whether the system 10 is coupled to the network 34 as 
indicated in diamond 84. If so, the BIOS module 40 may be 
5 downloaded from storage 3 8 associated with the server 36 
over the network 34, In this case, because the system is 
network connected, not only may a name be required, but a 
personal identification number (PIN) may also be required 
as well. Alternatively, other heightened security 

10 procedures may be invoked such as a requirement of the use 
of a smart card and smart card reader 48 and 46. 

If the system is not network connected, a BIOS module 
may be loaded from the ROM 50. Since the system is not 
network connected, a more limited authentication protocol 

15 may be implemented, for example requesting only a PIN 
without a name as indicated in block 92. 

In some embodiments of the present invention, the BIOS 
may be broken down on logically self -encapsulated modules. 
The execution and the presence of each module is optional. 

20 A particular module may be present (or not) depending on 
system state, and the needs of a particular system. 
Similarly, a particular module may be executed or it may be 
skipped depending on the system policy, user choice or what 
is actually present on a particular system. 

2 5 For example, if a laptop computer is not connected to 

docking station and some BIOS modules are on the docking 
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station, those files may not be available to be executed. 
For example, a docking station may contain a smart card 
reader which may be used for authentication when the 
computer is connected to the docking station. Thus, the 
5 system state may change what may be executed. 

In some embodiments of the present invention, the 
distributed BIOS modules may be linked dynamically. A 
loader may be utilized to load the needed executable BIOS 
modules wherever located. 

10 Referring to Figure 6, a given functional module 108 

may have a predefined structure in accordance with one 
embodiment of the present invention. The module 10 8 may 
include a header 98 and the header 98 may include an entry 
point 100 which provides directions to locate one or more 

15 functions enabled by the module 108. Thus, the entry point 
100 may include a direction 102 to code 104 for a first 
function implemented by a module and a direction 106 which 
directs the flow to a code 107 for a second function 
defined within the module 108. Thus, once the entry point 

20 100 to the module 108 is located, its functions may be 
exposed. 

The entry points for each module, as an offset from 
the module's base address, are generally stored in other 
modules. Thus, if a first module, that stores an offset to 
25 an entry point for a second module, finds the base memory 

address for the second module, the first module may link to 
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the second module, in one embodiment of the present 
invention. A base memory address is defined by a shared 
descriptor table 100, shown in Figure 7. The descriptor 
table 100 stores information 112 about the base address 114 
5 for one or more modules 108. For example, the descriptor 
table 100 may provide information 112 sufficient to locate 
the base address 114 of one or more modules 108. Thus, the 
descriptor table 100 may have information 112a which 
locates the base address 114a of the module 108a. 

10 Once the base address is located, the entry point can 

be determined from the offset. The offset provides the 
information about where the entry point is located in the 
module relative to the base address of the module. Once 
the entry point is determined, any function within the 

15 module may then be located. 

The memory base address 114 is a segment address which 
is defined at run time. More particularly, depending on 
where a particular module 108 ends up being stored, the 
base address is provided to the descriptor table 100. The 

20 table 100 may then be checked by any module attempting to 
link to another module to locate the base address of a 
particular module. 

Thus, each module may export its entry point. It may 
do this by providing information about the structure of its 

25 header, naming conventions, length of the header, and check 
sums and finally an offset from a base address to the entry 
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point within the header. At run time, the segment address 
where the module was stored (and in particular its base 
address) is known. The segment address points to the 
location of the base address. The segment address 
5 information 112 may then be stored in the descriptor table 
100 . 

This allows the system processor to find appropriate 
free memory space to store the modules. An appropriate 
space is one which has sufficient size to store a given 

10 functional module 108 as expanded. 

Referring next to Figure 8, the flow 110 for linking 
BIOS modules begins by compiling a BIOS module 108, as 
indicated in block 112. A header is then attached to the 
functional BIOS module as indicated in block 114. The 

15 header provides the function number that is used to locate 
particular functions implemented by the module. The entry 
point information is exported (block 116) from one module 
to other modules. 

At run time, the system processor finds an appropriate 

2 0 free memory space to store each module, as indicated in 
block 118. An appropriate space is one which has 
sufficient size to store the given functional BIOS module 
as expanded. The information 112 to locate the base 
address of the module is prepared (block 120) , as indicated 

25 in block 120, and the functional BIOS module 108 is loaded 
into the free memory space at the base address (block 122) , 
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Thereafter, the module may be called by another module as 
indicated in block 124 . 

A module is called by accessing its segment address 
from the descriptor table 100. This information, together 
5 with the entry point, produces the information needed to 

locate each function, by function numbers, supported by the 
called module. 

In this way, one or more functional BIOS modules may 
be called by any other BIOS module to implement features 

10 which may or may not be desired in any particular system at 
any given time. For example, a PAS feature may or may not 
be utilized. A given module may be loaded and linked up 
depending on whether the system is network connected. For 
example, if the system is network connected, a functional 

15 BIOS module may be dynamically linked which provides 
enhanced authentication features. 

As another example, a set-up feature may be 
selectively called up as a dynamically linked functional 
module in some cases. The set-up module may allow the user 

20 to input system set-up preferences such as power 

management, the source for booting (such as a floppy or 
hard disk drive) , enabling specialized features such as hot 
docketing or any of a variety of conf igurational 
preferences. The set-up functional BIOS module may be 

25 called at run time depending on a system configuration or a 
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user preference. It may be called by dynamically linking 
in the fashion described above . 

As one additional example, the present invention may 
implement a so-called quiet boot feature. In quiet boot, 
5 the user elects not to see messages that come from BIOS 
during the boot process. These messages may be obscure 
(such as that the memory has been successfully 
initialized) . Instead, the user may receive a bit mapped 
image on the screen during the boot process, replacing the 
10 BIOS messages. However, the bit map may use a lot of 

memory space. Thus, some users may want quiet boot and 
some may not . 

In one embodiment of the present invention, after the 
user indicates whether or not the user wishes quiet boot in 

15 an original set up screen, the bit map files may be loaded 
only in those cases where the user actually has elected 
quiet boot and may not be loaded from a remote storage 
location in other cases. Thus, selected execution saves 
storage space except in those cases where the feature is 

20 actually utilized. This may be of considerable cost 

importance, since BIOS may be stored for example on flash 
memory and the flash memory may be used up by the bit 
mapped files. 

Some embodiments of the present invention have the 

25 ability, at run time, to load a piece of code and execute 
it, and then thereafter to reuse the memory space 
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previously used by that code, freeing up additional memory 
space occupied by such code for reuse. Moreover, BIOS 
modules may be loaded and executed on demand based on user 
preferences or conditionally based on system configuration, 
5 in some embodiments of the present invention. 

While the present invention has been described with 
respect to a limited number of embodiments, those skilled 
in the art will appreciate numerous modifications and 
variations therefrom. It is intended that the appended 
10 claims cover all such modifications and variations as fall 
within the true spirit and scope of this present invention. 

What is claimed is: 
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1 1. A method comprising: 

2 executing a first basic input/output system 

3 module; and 

4 dynamically linking to a second basic 

5 input/output system module. 

1 2. The method of claim 1 further comprising: 

2 storing said first module of a basic input/output 

3 system for a processor-based system on a first storage 

4 device prior to execution; 

5 storing said second module of the basic 

6 input /output system on a second storage device prior to 

7 execut ion ; and 

8 enabling said second module to be executed 

9 conditionally depending on a state of said processor-based 
10 system, 

1 3 . The method of claim 2 wherein storing said second 

2 module includes storing said second module in a storage 

3 associated with a network server accessible to said 

4 processor-based system over a network. 

1 4 . The method of claim 1 further including detecting 

2 said system state during the boot sequence. 
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1 5. The method of claim 4 including detecting whether 

2 or not the system is connected to a network during the boot 

3 operation . 

1 6, The method of claim 1 including dynamically 

2 linking to one of a plurality of modules, and exporting an 

3 offset to an entry point in one module to another module. 

1 7. The method of claim 6 including storing a 

2 secondary entry point in a module to locate a function 

3 within the module, 



1 8 . The method of claim 7 including developing a 

2 segment address for said second module at run time. 

1 9. The method of claim 8 including providing a 

2 descriptor table which indicates a segment address for said 

3 second module. 



1 10. An article comprising a medium for storing 

2 instructions that cause a processor-based system to: 

3 execute a first basic input/output system module; and 

4 dynamically link to a second basic input/output system 

5 module. 
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1 11. The article of claim 10 further storing 

2 instructions that cause a processor-based system to: 

3 access said first module of a basic input/output 

4 system on a first storage device; 

5 access said second module of the basic 

6 input/output system on a second storage device; and 

7 execute said second module conditionally 

8 depending on the state of said processor-based system. 

1 12, The article of claim 11 further storing 

2 instructions that cause a processor-based system to access 

3 said second module in a storage associated with a network 

4 server accessible to said processor-based system over a 

5 network . 

1 13. The article of claim 11 further storing 

2 instructions that cause a processor-based system to execute 

3 said second module conditionally depending on whether or 

4 not the processor-based system is coupled to a network. 

1 14. The article of claim 11 further storing 

2 instructions that cause a processor-based system to 

3 selectively access either a first module setting forth a 

4 first authentication protocol in a first storage device or 

5 a second module setting forth a second authentication 

6 protocol in a second storage device. 
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1 15. The article of claim 11 further storing 

2 instructions that cause a processor-based system to 

3 dynamically link said first and second modules. 

1 16. The article of claim 11 further storing 

2 instructions that cause a processor-based system to detect 

3 said system state during the boot sequence. 

1 17, The article of claim 16 further storing 

2 instructions that cause a processor-based system to 

3 whether the system is connected to a network during 

4 boot operation. 

1 18. The article of claim 11 further storing 

2 instructions that cause a processor-based system to 

3 dynamically link to one of a plurality of modules using 

4 offsets to entry points in said modules. 

1 19. The article of claim 18 further storing 

2 instructions that cause a processor-based system to store a 

3 secondary entry point in a module to locate a function 

4 within the module. 



detect 
the 



21 



1 20. The article of claim 19 further storing 

2 instructions that cause a processor-based system to develop 

3 a segment address for said second module at run time, 

1 21. The article of claim 20 further storing 

2 instructions that cause a processor-based system to provide 

3 a descriptor table which identifies the segment address for 

4 said second module. 

1 22. A processor-based system comprising: 

2 a processor; 

3 a first basic input/output system module 

4 executable by said processor; and 

a second basic input/output system module 
executable by said processor, said second module being 
dynamically linked to said first module. 

1 23. The system of claim 22 including a detector that 

2 detects a system state to determine whether said processor 

3 executes said second module. 

1 24, The system of claim 22 including a first storage 

2 for said first module and a second storage for said second 

3 module, said second storage being coupled to said 

4 processor-based system over a network. 
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1 25. The system of claim 24 wherein said detector 

2 detects information about network access. 

1 26. The system of claim 25 wherein said first and 

2 second modules include different authentication protocols. 

1 27. The system of claim 26 wherein said processor 

2 executes said basic input/output system module on said 

3 second storage to implement a network authentication 

4 protocol . 

1 28. The system of claim 22 wherein said first module 

2 dynamically links to said second module, using an offset 

3 exported from said second module. 

1 29. The system of claim 28 wherein said first module 

2 uses a secondary entry point to locate a function in said 

3 second module. 

1 30. The system of claim 22 wherein said processor 

2 provides a descriptor table which includes a segment 

3 address for said second module. 
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DYNAMICALLY LINKED BASIC INPUT/OUTPUT SYSTEM 

Abstract of the Disclosure 
A basic input/output system may include two modules 
one of which may be dynamically linked to the other. A 
first BIOS module may dynamically link to a second BIOS 
module. The BIOS modules may be stored in the same or 
different memories. One BIOS module may be executed 
conditionally. A function in a BIOS module may be 
dynamically linked through a header entry point. 
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AhcMTiey's Docket No-: n^rt -caM JLJ5 /py88g> PMBSL 
ppr.i ARftTiHM mn mw£R QF ATTOFtNE Y FOR PATENT A PPUCATlQN 

As a bekw named inventor, I hereby dedare that 

My residencB, post office address and dfeenship are as steMed fadow, next to my name. 

I believe I am the eriginad. first, and sol© inventor (if only one name Is listed bdow) or an 
ortQinal, first, and joint ifjver»»r (if plural names are listed bdow) of the su^eot matter 
which 18 claimed and for whid^ a patent is sought on the invwHon entilied 

DYNAMICALLY LINKED BASIC 1^4PlrTraUTPllT SYSTEIVI 
tlie specfficatlon of which 



X_J is auadied hereto. 

waafiledon as 

Uni(ed States Application Nmnber 



or PCT tnternatioial Applicatfon Number 
and was amended (») 



(Jd a$>plicabte) 



1 hereby state that I havs reviewed and understand the contents of tl» above-Wenfified 
spedficaKon, indudlng the daini(s}, as amended by any amendment refemad to above, f 
do not know and do not believe thai the claimed Invention \waa ever known or used In the 
United States of Amertes befons my Invention thereof, or patented or described irt any 
printed publication in any country b^re rry InvenlSor^ Iheneof or mom than one year prior 
to this applicadon. that the same was not in publio use or on sale in (he United Stste* of 
America more than one year prior to this application, and that the Invention has not been 
patented or made the subiect of an Inventor^ certificate Issued beton* the <tete of this 
appticalion in any coynlry ftireign lo the United Stales of Ameiica on an application filed by 
me or my tegal representaBves or sett^n^ more than Wfelve months {for » uhlity patent 
application) or six nwnJhs {for a design patent appBcatfon) prior tn Ms appBcalion. 

1 acknowladge flie duty to disclose all iifonrotion Hnown to me Id be material to 
patentabiyty as defined in Title 37, CJode of Federd FtegU^ns, Sec«on 1 .56. 

I hereby claim foreign priority benefits under Title 35, United Stales Code, Secfion 1 19(^ 
(d), of any foreign applicatiOrt(s) for patent or inventor's certificale listed below and have 
also Wentlfied below any foreign application for patent or inventor's oertSicalB havino a 
fBIng date before tf»at of the applicafion on whid^ priori^ is claimed: 

Prior Foreign Atarficatkinfe^: Priority Claimed 

Nirib« (Oountry) (DayrttoittVYear Filed) "yS No 



ISimbir (Courwy) (Day/MonWYear Red) Yes No 



"NkSbS^ (Country) (Pay/MomWYearFited) Yes No 
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I hereby claim Ifrfe benem under title 33, United States Code, Section 119(6) of the United 
States provisional app1ication(s) listed bekiw: 



^pplcdecr Number) (Fr»ig o^) 



(Appficalton Number) (Rling Dale) 

t hei^by daim the benefit under Titfe 35, United States Code, Section 120 <rf any UnHed 
States ap|[*catton^s) iiated below ^nd« in^^ the subject matter of Mch of the claims 
cf thte Q?>plication is not dfedosed In tta prior UnHed States application in the manner 
piPVldod by ttie first paragraph of Title 35, United States Code, Sedion 112, I 
acknowledge the duty to disclose aif informatfon know to me to be matertat to 
patentabiii^ ^ defined in Tftle 37, Code of Federal r^ufatiOTS, Section 1-58 whic*i 
became av^bble between the filing date of the prior application and the natk^l or PCT 
Intematicnal tJSng date of this application; 



lApptica^ionMi^iber} FKng Dale (^aa«-pa«wteci, pere^g, ab^ndotied) 

^llcs^csn^lurT^ Fling Dgte ' {Status--patented, pendingi abgiKJoned} 



i tiereby appoint Timothy Trop. Reg. No. 28,994; Fred G. Pruner, Jr., Reg- No. 40,779, 
Dan C. Hu, Reg. No, W,C26; Coe F. Mile^. Reg^ No. 38,659, »nd John R. Meriding, Reg. 
No. 31,716 my patent attorneys, of TROP, PRUNER. HU & MILES. P,C., with offices 
located at 8554 Katy Freeway. Ste. 1C^, Houston, TX 77024, telephone (713) 46&<880, 
and Joseph R, Bond. R^. No, 36,458^ Richard C. Cakferwood, Reg, No, 35.468; Sean 
Fit^erald, Reg. No. 32,027; David J, Kaplan, Reg, No- 41,105; Leo V. Novakosfc, R»g, 
No. 37,198; Naomi Obrnata, Reg. No, 39320; Thomas C. Reynolda, Reg. No. 32,488; 
Steven P. Skabrat, Reg. No. 36,i7S; Howard A. Skafet, Reg. No. 38,008; Steven C. 
Stewart, Reg. No, 33,S55; Raymond J, Werner, Reg. No. 34.752; and Chartes K. Young. 
Reg. No. 39,425; my patent attorn^, of INTEL CORPORATION; with full power of 
substitution and iWOCSfcn , to pro$0CMte this applfcafion and ix> transact all business in flie 
Patent and Tf^mark Offi^ connected herevwIJi, 

Send correspondence to Iirnoth y N. Tecp . TROP, PRUNER, HU & MILES, P.O., 8554 
Katy Freeway, Ste. 100, Houston, TX 77024 and dnect telephone calls to 
mt^t^y N.Trop (713) 463^880. 

I hereby dedare that all statements made herein Of my own knovi^dge are true and that 
all ^telements i^ade on infafmeseon and be«9f are believed to be true; and further that 
mese statements wsfB made v/ith the knowledge tSal waiful false st^eraents and Ihe like 
so made are punishable by Une or imprisonment, or boift, under SscSon 1001 of Trtle 18 of 
t»ie United States Code mi that sudi wilHiil latee statements may ieopaidize the vallcfify of 
the appflcatton or any patent Issued theneon. 
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Full Ntefifve of Sol«/Ffrst Inventop: 




AUEX L EYDEtfeERG 






Dale; , . 
/cl/C?6/ 


Residence! 




DAUY CiTY, CALIFORNIA 




Pwt Office Adctresfi! 




331 BARSARA LANE, DALY CIT^, CAUFORNIA 94015 
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